Self-driving vehicle&#39;s response to a proximate emergency vehicle

ABSTRACT

A computer-implemented method, system, and/or computer program product controls self-driving vehicles (SDVs). An emergency message is transmitted to a receiver within a self-driving vehicle (SDV). The emergency message describes an emergency state of an emergency vehicle and an identified future route of the emergency vehicle, where the identified future route is a planned route to an emergency destination for the emergency vehicle that includes a first pathway. In response to the SDV receiving the emergency message, the SDV is redirected, via an auto-control hardware system on the SDV, to drive to a second pathway that does not conflict with the identified future route of the emergency vehicle.

BACKGROUND

The present disclosure relates to the field of vehicles, andspecifically to the field of self-driving vehicles. Still morespecifically, the present disclosure relates to the field ofself-driving vehicles responding to nearby emergency vehicles.

Self-driving vehicles (SDVs) are vehicles that are able to autonomouslydrive themselves through private and/or public spaces. Using a system ofsensors that detect the surroundings of the SDV, logic within orassociated with the SDV controls the propulsion, stopping, and steeringof the SDV based on the sensor-detected surroundings of the SDV.

SUMMARY

A computer-implemented method controls self-driving vehicles (SDVs). Anemergency message is transmitted to a receiver within a self-drivingvehicle (SDV). The emergency message describes an emergency state of anemergency vehicle and an identified future route of the emergencyvehicle, where the identified future route is a planned route to anemergency destination for the emergency vehicle that includes a firstpathway. In response to the SDV receiving the emergency message, the SDVis redirected, via an auto-control hardware system on the SDV, to driveto a second pathway that does not conflict with the identified futureroute of the emergency vehicle.

A computer program product and/or computer system controls self-drivingvehicles (SDVs). An emergency message is transmitted to a receiverwithin a self-driving vehicle (SDV). The emergency message describes anemergency state of an emergency vehicle and an identified future routeof the emergency vehicle, where the identified future route is a plannedroute to an emergency destination for the emergency vehicle thatincludes a first pathway. In response to the SDV receiving the emergencymessage, the SDV is redirected, via an auto-control hardware system onthe SDV, to drive to a second pathway that does not conflict with theidentified future route of the emergency vehicle. In response to thereceiver within the SDV receiving the emergency message, real-timecurrent traffic patterns of a current location of the SDV areautomatically transmitted to the emergency vehicle, where the real-timecurrent traffic patterns are generated based on positioning signalsgenerated by positioning systems in multiple SDVs that are in thecurrent location of the SDV.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an exemplary system and network in which the presentdisclosure may be implemented;

FIG. 2 illustrates an exemplary emergency vehicle and a self-drivingvehicle (SDV) on a potential adverse course;

FIG. 3 depicts communication linkages among an emergency vehicle, anSDV, and a coordinating server;

FIG. 4 illustrates additional details of components used within an SDVin accordance with one or more embodiments of the present invention;

FIG. 5 depicts additional details of components used within an emergencyvehicle in accordance with one or more embodiments of the presentinvention;

FIG. 6 is a high-level flow chart of one or more steps performed by oneor more processors to control an SDV when proximate to an emergencyvehicle;

FIG. 7 depicts a cloud computing node according to an embodiment of thepresent disclosure;

FIG. 8 depicts a cloud computing environment according to an embodimentof the present disclosure; and

FIG. 9 depicts abstraction model layers according to an embodiment ofthe present disclosure.

DETAILED DESCRIPTION

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Java, Smalltalk, C++ or the like,and conventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

With reference now to the figures, and in particular to FIG. 1, there isdepicted a block diagram of an exemplary system and network that may beutilized by and/or in the implementation of the present invention. Someor all of the exemplary architecture, including both depicted hardwareand software, shown for and within computer 101 may be utilized bysoftware deploying server 149 shown in FIG. 1, and/or coordinatingserver 501, emergency vehicle 202, and/or self-driving vehicle (SDV) 206depicted in FIG. 5 and other figures.

Exemplary computer 101 includes a processor 103 that is coupled to asystem bus 105. Processor 103 may utilize one or more processors, eachof which has one or more processor cores. A video adapter 107, whichdrives/supports a display 109, is also coupled to system bus 105. Systembus 105 is coupled via a bus bridge 111 to an input/output (I/O) bus113. An I/O interface 115 is coupled to I/O bus 113. I/O interface 115affords communication with various I/O devices, including a keyboard117, a mouse 119, a media tray 121 (which may include storage devicessuch as CD-ROM drives, multi-media interfaces, etc.), a transceiver 123(capable of transmitting and/or receiving electronic communicationsignals), and external USB port(s) 125. While the format of the portsconnected to I/O interface 115 may be any known to those skilled in theart of computer architecture, in one embodiment some or all of theseports are universal serial bus (USB) ports.

As depicted, computer 101 is able to communicate with a softwaredeploying server 149 and/or other devices/systems (e.g., coordinatingserver 501, emergency vehicle 202, and/or self-driving vehicle (SDV) 206depicted in FIG. 5 and other figures) using a network interface 129.Network interface 129 is a hardware network interface, such as a networkinterface card (NIC), etc. Network 127 may be an external network suchas the Internet, or an internal network such as an Ethernet or a virtualprivate network (VPN). In one or more embodiments, network 127 is awireless network, such as a Wi-Fi network, a cellular network, etc.

A hard drive interface 131 is also coupled to system bus 105. Hard driveinterface 131 interfaces with a hard drive 133. In one embodiment, harddrive 133 populates a system memory 135, which is also coupled to systembus 105. System memory is defined as a lowest level of volatile memoryin computer 101. This volatile memory includes additional higher levelsof volatile memory (not shown), including, but not limited to, cachememory, registers and buffers. Data that populates system memory 135includes computer 101's operating system (OS) 137 and applicationprograms 143.

OS 137 includes a shell 139, for providing transparent user access toresources such as application programs 143. Generally, shell 139 is aprogram that provides an interpreter and an interface between the userand the operating system. More specifically, shell 139 executes commandsthat are entered into a command line user interface or from a file.Thus, shell 139, also called a command processor, is generally thehighest level of the operating system software hierarchy and serves as acommand interpreter. The shell provides a system prompt, interpretscommands entered by keyboard, mouse, or other user input media, andsends the interpreted command(s) to the appropriate lower levels of theoperating system (e.g., a kernel 141) for processing. While shell 139 isa text-based, line-oriented user interface, the present invention willequally well support other user interface modes, such as graphical,voice, gestural, etc.

As depicted, OS 137 also includes kernel 141, which includes lowerlevels of functionality for OS 137, including providing essentialservices required by other parts of OS 137 and application programs 143,including memory management, process and task management, diskmanagement, and mouse and keyboard management.

Application programs 143 include a renderer, shown in exemplary manneras a browser 145. Browser 145 includes program modules and instructionsenabling a world wide web (WWW) client (i.e., computer 101) to send andreceive network messages to the Internet using hypertext transferprotocol (HTTP) messaging, thus enabling communication with softwaredeploying server 149 and other systems.

Application programs 143 in computer 101's system memory (as well assoftware deploying server 149's system memory) also include Self-DrivingVehicle Warning and Control Logic (SDVWCL) 147. SDVWCL 147 includes codefor implementing the processes described below, including thosedescribed in FIGS. 2-6. In one embodiment, computer 101 is able todownload SDVWCL 147 from software deploying server 149, including in anon-demand basis, wherein the code in SDVWCL 147 is not downloaded untilneeded for execution. In one embodiment of the present invention,software deploying server 149 performs all of the functions associatedwith the present invention (including execution of SDVWCL 147), thusfreeing computer 101 from having to use its own internal computingresources to execute SDVWCL 147.

Also within computer 101 is a positioning system 151, which determines areal-time currently location of computer 101 (particularly when part ofan emergency vehicle and/or a self-driving vehicle as described herein).Positioning system 151 may be a combination of accelerometers,speedometers, etc., or it may be a global positioning system (GPS) thatutilizes space-based satellites to provide triangulated signals used todetermine two or three dimensional locations.

The hardware elements depicted in computer 101 are not intended to beexhaustive, but rather are representative to highlight essentialcomponents required by the present invention. For instance, computer 101may include alternate memory storage devices such as magnetic cassettes,digital versatile disks (DVDs), Bernoulli cartridges, and the like.These and other variations are intended to be within the spirit andscope of the present invention.

With reference now to FIG. 2, an exemplary emergency vehicle 202 and aself-driving vehicle (SDV) 206 are depicted as being on a potentialadverse course. That is, assume that emergency vehicle 202 (e.g., anambulance, a police vehicle, a fire truck, etc.) is traveling on street204 on the way to the scene of an emergency (e.g., a fire, accident,sick/injured person, etc.). Assume further that SDV 206 is traveling onstreet 210, which intersects with street 204 (and thus the intendedroute of emergency vehicle 202). If SDV 206 continues along street 210,then there is a likelihood that SDV 206 will impede the progress ofemergency vehicle 202, if not actually collide with emergency vehicle202. Thus, the present invention places SDV 206 into an autonomousself-driving mode to redirect the SDV 206 to a location (e.g., turningonto street 208, stopping on street 210, slowing down to move to alocation that does not enter street 204, etc.) that does not impede theprogress of emergency vehicle 202. That is, the SDV 206 does not enterstreet 204 until the emergency vehicle 202 passes by.

As indicated by the name, SDV 206 is a vehicle that is capable of beingself-driven in an autonomous manner. SDV 206 may be a land-based vehicle(i.e., an automobile, a truck, self-propelled construction equipmentsuch as a crane, etc.), a waterborne vehicle (i.e., a boat), or anairborne vehicle (i.e., an airplane, a helicopter, etc.). As such, theemergency vehicle 202 may likewise be land-based (e.g., an ambulancewhose travel may be impeded by an SDV car without the presentinvention), waterborne (e.g., a fire boat whose travel to a fire may beimpeded by an SDV boat without the present invention), or even airborne(e.g., a medical helicopter whose travel to an emergency location orhospital may be impeded by an SDV airborne drone or SDV passengerhelicopter without the present invention).

With reference now to FIG. 3, additional detail of components used tocontrol SDV 206 in accordance with one or more embodiments of thepresent invention is presented.

As depicted in FIG. 3, SDV 206 includes a receiver 301 (incorporatingthe receiving hardware found in analogous transceiver 123 depicted inFIG. 1). Receiver 301 is electronically coupled (wired or wirelessly) toan SDV control processor 303 (analogous to processor 103 shown in FIG.1), which is electronically coupled to SDV vehicular physical controlmechanisms 305.

SDV vehicular physical control mechanisms 305 include some or all of thephysical components of SDV 206 required to control the movement of SDV206. For example, if SDV 206 is a car, then SDV vehicular physicalcontrol mechanisms 305 may be a throttle (e.g., components used tocontrol engine fuel injectors), a steering mechanism (e.g.,rack-and-pinion steering linkage), a braking mechanism (e.g., diskbrakes on the wheels), etc. That is, SDV vehicular physical controlmechanisms 305 are physical components of SDV 206 that control itsmovement, including acceleration, steering, braking, etc.

Similarly, if SDV 206 is a boat, then SDV vehicular physical controlmechanisms 305 may be a throttle (e.g., components used to controlengine fuel injectors), a steering mechanism (e.g., a rudder), areversing mechanism (e.g., reverse thrusters), etc. That is, SDVvehicular physical control mechanisms 305 are physical components of SDV206 that control its movement, including acceleration, steering,reversing, etc.

Similarly, if SDV 206 is a drone, then SDV vehicular physical controlmechanisms 305 may be a throttle (e.g., components used to control powerto the drone's engines), a steering mechanism (e.g., cyclic control ofrotary wings), an elevation control (i.e., collective control thatadjusts the pitch of rotary wings to make the drone go up or down), etc.That is, SDV vehicular physical control mechanisms 305 are physicalcomponents of SDV 206 that control its movement, including acceleration,steering, elevation, etc.

As shown in FIG. 3 and described in further detail herein, SDV 206 mayalso include a transmitter (e.g., a transmitting component of thetransceiver 123 shown in FIG. 1), which is able to transmit informationmessages to emergency vehicle 202 shown in FIG. 2 and/or coordinatingserver 501 shown in FIG. 5.

Also within SDV 206 is an SDV map display 309 (analogous to display 109shown in FIG. 1), which is an electronic display capable of displaying aposition of SDV 206 and/or emergency vehicle 202 and/or recommendedalternative routes for SDV 206 on an electronic map.

With reference now to FIG. 4, additional detail of components usedwithin emergency vehicle 202 in accordance with one or more embodimentsof the present invention is presented.

A transmitter 423 (e.g., a transmitting component of the transceiver 123shown in FIG. 1) allows the emergency vehicle 202 to transmit 1) anemergency status message of the emergency vehicle 202, and 2) areal-time position of the emergency vehicle 202. This information cancome from an emergency vehicle alert controller 401 (analogous tocomputer 101 shown in FIG. 1), which determines and/or receives anindication of the emergency status of the emergency vehicle 202.

As shown in FIG. 4 and described in further detail herein, emergencyvehicle 202 may also include a receiver (e.g., a receiving component ofthe transceiver 123 shown in FIG. 1), which is able to receiveinformation messages from SDV 206 shown in FIG. 2 and/or coordinatingserver 501 shown in FIG. 5.

Also within emergency vehicle 202 is an emergency vehicle map display409 (analogous to display 109 shown in FIG. 1), which is an electronicdisplay capable of displaying a position of emergency vehicle 202 and/orSDV 206 and/or recommended alternative routes for emergency vehicle 202on an electronic map.

With reference now to FIG. 5, communication linkages among emergencyvehicle 202, SDV 206, and/or a coordinating server 501 are presented.That is, in one or more embodiments of the present invention, emergencyvehicle 202 directly communicates with SDV 206, thus directing SDV 206to adjust its route in order to avoid impeding the travel of emergencyvehicle 202. In another embodiment however, all coordination of themovement of emergency vehicle 202 and/or SDV 206, as well as theestablishment of an emergency state (and thus engagement of anautonomous self-driving mode in SDV 206), is achieved under thesupervision of coordinating server 501.

With reference now to FIG. 6, a high-level flow chart of one or moresteps performed by one or more processors to control an SDV whenproximate to and/or in a position that may impede the travel of anemergency vehicle is presented.

After initiator block 602, an emergency vehicle (e.g., emergency vehicle202 shown in FIG. 2) and/or a coordinating server (e.g., coordinatingserver 501 shown in FIG. 5) transmit an emergency message to a receiver(e.g., receiver 301 shown in FIG. 3) within a self-driving vehicle (SDV)(e.g., SDV 206 shown in FIG. 2), as described in block 604. Thisemergency message describes an emergency state of an emergency vehicleand an identified future route of the emergency vehicle. That is, theemergency message indicates that the emergency vehicle is on anemergency run, in which it needs to get to its destination as soon assafely possible, and it describes the present position of the emergencyvehicle and the route that the emergency vehicle will be taking to getto its destination.

As indicated in query block 606, a determination is made as to whetheror not the emergency message has been received by the SDV. If so, thenthe SDV is redirected, via an auto-control hardware system on the SDV(e.g., SDV control processor 303 along with the SDV vehicular physicalcontrol mechanisms 305 shown in FIG. 3), to a location that does notconflict with the identified future route of the emergency vehicle (seeblock 608). For example, the auto-control hardware system mayautomatically cause the SDV to pull over and/or stop on the side of road(e.g., pull over to the side of street 210 shown in FIG. 2); to slowdown on its current street (e.g., slow down on street 210 shown in FIG.2, such that emergency vehicle 202 is able to get past the intersectionof street 204 and street 210 before the SDV 206 reaches thatintersection); to turn down another street (e.g., to turn onto street208 shown in FIG. 2, thus avoiding street 204 while the emergencyvehicle 202 is nearby); etc.

The identified future route of the emergency vehicle may beidentified/determined in various ways. For example, the emergencymessage may include a current real-time location of the emergencyvehicle and a destination address of the emergency vehicle. Using thisinformation, the intended route of the emergency vehicle can be derivedand plotted on a digital map, or the planned route information can betransmitted.

Similarly, the identified future route of the emergency vehicle may behistoric-based. That is, assume that the emergency vehicle is anambulance that is returning from a call. If this ambulance is based at aparticular hospital, then an assumption can be made that this particularhospital is the location/destination at the end of the identified futureroute (i.e., where the emergency vehicle is going) of the emergencyvehicle.

Alternatively, assume that the patient in the ambulance is a traumavictim, and that the local county has one Level I trauma hospital. Byinputting this information into the on-board system of the emergencyvehicle (e.g., emergency vehicle alert controller 401 shown in FIG. 4),then the route from the current real-time position of the emergencyvehicle to the Level I trauma hospital can be derived/identified.

The flow-chart shown in FIG. 6 ends at terminator block 610.

In an embodiment of the present invention, the SDV is initiallyoperating in manual mode, such that the SDV is manually controlled by adriver of the SDV. Thus, in response to the receiver within the SDVreceiving the emergency message, one or more processors (e.g., withinthe SDV) automatically switch control of the SDV from the manual mode toan autonomous mode, thereby allowing the autonomous mode to direct theauto-control hardware system on the SDV to autonomously control movementof the SDV. That is, initially the SDV is actually not self-driving, butrather is under the control of a person who is driving the vehicle,either on-board (e.g., if the SDV is a passenger vehicle) or remotely(e.g., if the SDV is a drone). However, once the SDV receives theemergency message from the emergency vehicle, directing the SDV and/orother vehicles to clear the pathway being taken by the emergencyvehicle, the SDV goes into self-driving mode, such that the SDV isautonomously/automatically steered/moved/positioned to a location thatwill not impede the travel/route of the emergency vehicle. If theself-driving vehicle determines the manual driving mode is to remain inplace, it informs the driver over voice, flash message and/or textand/or images/videos about the oncoming emergency vehicle and whatshe/he needs to do in order to allow the emergency vehicle to pass bysafely. Moreover, if the self-driving car finds one or more obstacles onthe lane/road on which the emergency vehicle is going to come, itinforms the emergency vehicle of the same over network connection. Italso attempts to inform the obstacle—if it is another vehicle or suchother object, to clear the lane or road for the emergency vehicle.

In an embodiment of the present invention, the emergency vehicle and/orthe supervisory server transmits, to the receiver within the SDV, amessage describing the identified route of the emergency vehicle. Thisallows the SDV to determine autonomously the best evasive action to betaken. For example, if the emergency vehicle is on a route that is veryclose to the SDV, then the SDV may simply pull off to the shoulder onthe side of the road. However, if the emergency vehicle is on anidentified route that is far enough away from the SDV, then the SDV canslow down, turn down a side street, or continue and monitor the positionof the emergency vehicle, etc.

In an embodiment of the present invention, the emergency message(describing the emergency state of the emergency vehicle) is transmitted(from the emergency vehicle or a supervisory system/server/computer) tothe receiver within the SDV in response to a warning system beingactivated within the emergency vehicle, where the warning system warnsthe SDV of an emergency state of the emergency vehicle. For example, theemergency vehicle alert controller 401 shown in FIG. 4 may turn onflashing lights and a siren on the emergency vehicle (depicted asemergency warning devices 407 in FIG. 4), as well as automaticallytransmitting the emergency message to the SDV via the transmitter 423.That is, activation of the siren/flashing lights occurs at the same timethat the warning emergency message is sent to the SDV.

In an embodiment of the present invention, one or more processors(within the SDV 206 and/or the coordinating server 501 shown in FIG. 5)adjust a level of autonomous control of the SDV by the auto-controlhardware system on the SDV based on traits of non-driver occupants inthe SDV. For example, assume that a profile containing traits ofnon-driver occupants (e.g., passengers, pets, children, fragile cargo,etc.) shows that a sudden braking or other movement of the SDV mayresult in injury/damage to the occupants. That is, if an occupant is asmall unrestrained dog, then sudden braking may result in the dog beingthrown to the floor of the vehicle. As such, the auto-control hardwaresystem (e.g., SDV control processor 303 and SDV vehicular physicalcontrol mechanisms 305 shown in FIG. 3) will bring the SDV to a stopmore slowly than if the dog was not in the SDV.

In an embodiment of the present invention, one or more processors (e.g.,within the SDV 206 and/or the coordinating server 501 shown in FIG. 5)retrieve data describing historic traffic patterns of the identifiedroute and then adjust, using the auto-control hardware system on theSDV, the redirection of the SDV according to the historic trafficpatterns of the identified route. For example, assume that historicaldata shows that street 208 in FIG. 2 is always backed-up at a certaintime of day/week. If the SDV 206 is approaching the intended route ofthe emergency vehicle 202 at that time of day/week, then the system willnot put the SDV 206 onto street 208, but rather will cause it to slowdown, pull off to the shoulder of street 210, etc., rather than addingSDV 206 to the backup on street 208.

In an embodiment of the present invention, in response to the receiverwithin the SDV receiving the emergency message, real-time currenttraffic patterns of a current location of the SDV are automaticallytransmitted to the emergency vehicle. For example, in FIG. 2, assumethat traffic is currently backed up on street 210. SDV 206 willbroadcast this information to emergency vehicle 202 (either directly orvia the coordinating server 501 shown in FIG. 5), thus letting theemergency vehicle 202 know that it is inadvisable to turn down street210.

In an embodiment of the present invention, in response to receiverswithin multiple SDVs receiving the emergency message, multipleprocessors automatically transmit real-time current traffic patterns ofcurrent locations of the multiple SDVs to the emergency vehicle. Thatis, rather than just moving a single SDV out of the path of theemergency vehicle, a coordinated movement of multiple SDVs will clear apathway for the emergency vehicle, thus overcoming the problem of anyone SDV having no place to move to.

Thus, in an embodiment of the present invention, real-time currenttraffic patterns of current locations of the multiple SDVs are received(e.g., by the coordinating server 501 shown in FIG. 5) from multipleSDVs along the identified route of the emergency vehicle. Usingauto-control hardware systems on the multiple SDVs, the SDVs areredirected to positions that clear out a new route for the emergencyvehicle. A redirection message is then sent to the emergency vehicle,which redirects the emergency vehicle to the new route. For example, ifmultiple SDVs are traveling on street 204 in FIG. 2, and street 204 isthe intended route for the emergency vehicle 202, then these other SDVs(not shown in FIG. 2) will instruct the emergency vehicle 202 to take analternate route (e.g., streets 210 and 208).

In an embodiment of the present invention, the SDV is equipped with aminimum spacing device that automatically maintains a predefined minimumdistance between the SDV and another vehicle. In this embodiment, inresponse to the SDV receiving the emergency message, the predefinedminimum distance between the SDV and the other vehicle isadjusted/modified. For example, assume that the SDV has a system thatmaintains a 100-foot cushion around the SDV whenever the SDV istraveling at a speed of 30 miles per hour. While this amount of cushionwill certainly ensure that the SDV will not rear end another vehicle orbe rear-ended itself, it dramatically slows down (and thus increases)traffic on the street. Thus, when an emergency vehicle is in an“emergency state” as described herein, the buffer around the SDV will beshrunk, allowing a pathway to be created for the emergency vehicle totravel through.

As described herein, the present invention communicatively couples oneor more emergency vehicles and at least one SDV (self-driving vehicle).The emergency vehicle, when in alerting mode (e.g., a siren is on),communicates a verification signal to the SDV indicating that automaticdriving mode is required. The vehicle responds by confirming receipt ofthe verification signal, and switches into automatic driving mode(unless overridden by the human driver or by other conditions thatrequire manual driving), thus moving out of the emergency vehicle's pathin concert with other vehicles.

As described herein in one or more embodiments, the emergency vehicleenters emergency alerting mode (e.g., siren is on), and then broadcastsa verification signal to all SDVs within the vicinity of the emergencyvehicle. The SDVs detect the verification signal and switch to automaticdriving mode automatically (unless overridden by the human driver or byother conditions that require manual driving) and modify at least onedriving behavior (of the SDV) in order to organize a concerted effort ofclearing a path for the emergency vehicle.

In an embodiment of the present invention, the SDV's destinationlocation is modified if it interferes with the destination of theemergency vehicle. For example, assume that the emergency vehicle isheaded to a car fire. Even if the SDV will not interfere with theemergency vehicle as it is traveling to the car fire, the SDV willnonetheless be redirected away from the car fire, in order to avoidinterfering with the work of the emergency responders to the car fire.

In one embodiment, when an emergency vehicle determines the route fromits location to destination, it informs all the SDVs on that route usinga central server or by adhoc routing among SDVs. The SDVs then engage ina concerted effort to clear a lane a few minutes before the emergencyvehicle arrives. If there are reports of issues and incidents reportedby SDVs along the route, the emergency vehicle updates the route basedon its policy. The policy specifies the priority of issues and incidentsreported by SDVs and whether or not to change routes based on thispolicy.

In one embodiment of the present invention, a weighted voting system isused to weight the various variables used in making the decisionsregarding SDV mode and movement. Such inputs may include: a history ofpedestrians wishing to cross at a particular intersection or point in aroad, the distance a pedestrian is from the side of the road, other carsstopping nearby to allow pedestrian crossings, votes by nearby cars,etc. Such weighted voting approaches may be characterized primarily bythree aspects—the inputs, the weights, and the quota. The inputs are(I1, I2, . . . IN), where “N” denotes the total number of inputs. Aninput's weight (w) is the number of “votes” associated with the input. Aquota (q) is the minimum number of votes required to “pass a motion”,which in this case refers to a decision made by the SDV to alter itsroute.

In one embodiment of the present invention, active learning is employedto enable the system to learn from experiences of many SDVs and/ordrivers (e.g., in different geographies and among cohorts). Geographiesinclude, but are not limited to, cities, rural areas, etc. Cohortsinclude, but are not limited to, persons having the same or similarcertain characteristics, histories, distraction levels, etc.

For example, assume that historical data shows that SDVs have a historyof having to get out of the way of emergency vehicles at a particularintersection (e.g., near a hospital). As such, one embodiment of thepresent invention uses this historical data to predict (anticipate) thepresence of an emergency vehicle whenever the SDV approaches thisintersection, thus prompting the SDV to initiate preliminary steps toprepare the SDV for entering an autonomous driving mode.

Similarly, historical data may show that emergency vehicles areprevalent in an urban area, but rare in a rural area. As such, thesystem will anticipate (e.g., perform initial steps to prepare the SDVto enter autonomous control mode) the need to go into SDV autonomousmode and/or alter the route of the SDV in urban areas, but not in ruralareas.

With regard to cohorts, assume that a particular driver/occupant of anSDV has a characteristic (i.e., trait) found in other members of acohort that affects the drivers' ability to respond to emergencyvehicles. For example, assume that the driver/occupant of SDV 206 shownin FIG. 2 has a neurological disorder that makes quick reactionsdifficult. Assume further that a cohort of drivers/occupants of otherSDVs is made of persons having this same neurological disorder, and thathistorical data shows that these cohort members have a history ofaccidents with emergency vehicles when auto-control is 1) not activatedor 2) not available on the vehicle that the person was driving. As such,the system will anticipate that the SDV 206 needs to institute theautonomous control system described herein automatically whenever anemergency vehicle is detected nearby.

Thus, in one embodiment of the present invention, one or more processorsassign a driver of the SDV to a cohort of SDV drivers that each have(share) a particular trait, and then adjust a level of autonomouscontrol of the SDV by the auto-control hardware system on the SDV basedon traits of non-driver occupants in the SDV.

Furthermore, in one embodiment of the present invention, one or moreprocessors retrieve historical data related to (i.e., that describes) afrequency of activation of the autonomous mode in other SDVs in aparticular geography, and then adjust a level of autonomous control ofthe SDV by the auto-control hardware system on the SDV based on thefrequency of activation of the autonomous mode in the other SDVs in theparticular geography.

The present invention provides multiple advantages over the prior art.For example and as described herein, emergency vehicles (or supervisorysystems) not only alert SDVs of the presence of the emergency vehicle,but also orchestrate a concerted clearing of a path for the emergencyvehicle, even if this means directing the SDVs to keep driving (e.g.,along a narrow street or alleyway).

Automatic switching to automatic driving mode means that drivers'emotional responses become secondary, such that sirens and flashinglights on the emergency vehicle become less important.

The automatic switching to SDV mode described herein makes it no longernecessary for the driver to actually hear or see the warning signals(sirens/flashing lights) on the emergency vehicle, which can bedifficult to detect in a vehicle in which loud music is playing, ambientlighting masks the flashing lights on the emergency vehicle (e.g.,flashing neon signs along the road), etc.

In one or more embodiments, the present invention is implemented in acloud environment. It is understood in advance that although thisdisclosure includes a detailed description on cloud computing,implementation of the teachings recited herein are not limited to acloud computing environment. Rather, embodiments of the presentinvention are capable of being implemented in conjunction with any othertype of computing environment now known or later developed.

Cloud computing is a model of service delivery for enabling convenient,on-demand network access to a shared pool of configurable computingresources (e.g. networks, network bandwidth, servers, processing,memory, storage, applications, virtual machines, and services) that canbe rapidly provisioned and released with minimal management effort orinteraction with a provider of the service. This cloud model may includeat least five characteristics, at least three service models, and atleast four deployment models.

Characteristics are as follows:

On-demand self-service: a cloud consumer can unilaterally provisioncomputing capabilities, such as server time and network storage, asneeded automatically without requiring human interaction with theservice's provider.

Broad network access: capabilities are available over a network andaccessed through standard mechanisms that promote use by heterogeneousthin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling: the provider's computing resources are pooled to servemultiple consumers using a multi-tenant model, with different physicaland virtual resources dynamically assigned and reassigned according todemand. There is a sense of location independence in that the consumergenerally has no control or knowledge over the exact location of theprovided resources but may be able to specify location at a higher levelof abstraction (e.g., country, state, or datacenter).

Rapid elasticity: capabilities can be rapidly and elasticallyprovisioned, in some cases automatically, to quickly scale out andrapidly released to quickly scale in. To the consumer, the capabilitiesavailable for provisioning often appear to be unlimited and can bepurchased in any quantity at any time.

Measured service: cloud systems automatically control and optimizeresource use by leveraging a metering capability at some level ofabstraction appropriate to the type of service (e.g., storage,processing, bandwidth, and active user accounts). Resource usage can bemonitored, controlled, and reported providing transparency for both theprovider and consumer of the utilized service.

Service Models are as follows:

Software as a Service (SaaS): the capability provided to the consumer isto use the provider's applications running on a cloud infrastructure.The applications are accessible from various client devices through athin client interface such as a web browser (e.g., web-based e-mail).The consumer does not manage or control the underlying cloudinfrastructure including network, servers, operating systems, storage,or even individual application capabilities, with the possible exceptionof limited user-specific application configuration settings.

Platform as a Service (PaaS): the capability provided to the consumer isto deploy onto the cloud infrastructure consumer-created or acquiredapplications created using programming languages and tools supported bythe provider. The consumer does not manage or control the underlyingcloud infrastructure including networks, servers, operating systems, orstorage, but has control over the deployed applications and possiblyapplication hosting environment configurations.

Infrastructure as a Service (IaaS): the capability provided to theconsumer is to provision processing, storage, networks, and otherfundamental computing resources where the consumer is able to deploy andrun arbitrary software, which can include operating systems andapplications. The consumer does not manage or control the underlyingcloud infrastructure but has control over operating systems, storage,deployed applications, and possibly limited control of select networkingcomponents (e.g., host firewalls).

Deployment Models are as follows:

Private cloud: the cloud infrastructure is operated solely for anorganization. It may be managed by the organization or a third party andmay exist on-premises or off-premises.

Community cloud: the cloud infrastructure is shared by severalorganizations and supports a specific community that has shared concerns(e.g., mission, security requirements, policy, and complianceconsiderations). It may be managed by the organizations or a third partyand may exist on-premises or off-premises.

Public cloud: the cloud infrastructure is made available to the generalpublic or a large industry group and is owned by an organization sellingcloud services.

Hybrid cloud: the cloud infrastructure is a composition of two or moreclouds (private, community, or public) that remain unique entities butare bound together by standardized or proprietary technology thatenables data and application portability (e.g., cloud bursting forload-balancing between clouds).

A cloud computing environment is service oriented with a focus onstatelessness, low coupling, modularity, and semantic interoperability.At the heart of cloud computing is an infrastructure comprising anetwork of interconnected nodes.

Referring now to FIG. 7, a schematic of an example of a cloud computingnode is shown. Cloud computing node 10 is only one example of a suitablecloud computing node and is not intended to suggest any limitation as tothe scope of use or functionality of embodiments of the inventiondescribed herein. Regardless, cloud computing node 10 is capable ofbeing implemented and/or performing any of the functionality set forthhereinabove.

In cloud computing node 10 there is a computer system/server 12, whichis operational with numerous other general purpose or special purposecomputing system environments or configurations. Examples of well-knowncomputing systems, environments, and/or configurations that may besuitable for use with computer system/server 12 include, but are notlimited to, personal computer systems, server computer systems, thinclients, thick clients, hand-held or laptop devices, multiprocessorsystems, microprocessor-based systems, set top boxes, programmableconsumer electronics, network PCs, minicomputer systems, mainframecomputer systems, and distributed cloud computing environments thatinclude any of the above systems or devices, and the like.

Computer system/server 12 may be described in the general context ofcomputer system-executable instructions, such as program modules, beingexecuted by a computer system. Generally, program modules may includeroutines, programs, objects, components, logic, data structures, and soon that perform particular tasks or implement particular abstract datatypes. Computer system/server 12 may be practiced in distributed cloudcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed cloud computing environment, program modules may be locatedin both local and remote computer system storage media including memorystorage devices.

As shown in FIG. 7, computer system/server 12 in cloud computing node 10is shown in the form of a general-purpose computing device. Thecomponents of computer system/server 12 may include, but are not limitedto, one or more processors or processing units 16, a system memory 28,and a bus 18 that couples various system components including systemmemory 28 to processor 16.

Bus 18 represents one or more of any of several types of bus structures,including a memory bus or memory controller, a peripheral bus, anaccelerated graphics port, and a processor or local bus using any of avariety of bus architectures. By way of example, and not limitation,such architectures include Industry Standard Architecture (ISA) bus,Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnects (PCI) bus.

Computer system/server 12 typically includes a variety of computersystem readable media. Such media may be any available media that isaccessible by computer system/server 12, and it includes both volatileand non-volatile media, removable and non-removable media.

System memory 28 can include computer system readable media in the formof volatile memory, such as random access memory (RAM) 30 and/or cachememory 32. Computer system/server 12 may further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia. By way of example only, storage system 34 can be provided forreading from and writing to a non-removable, non-volatile magnetic media(not shown and typically called a “hard drive”). Although not shown, amagnetic disk drive for reading from and writing to a removable,non-volatile magnetic disk (e.g., a “floppy disk”), and an optical diskdrive for reading from or writing to a removable, non-volatile opticaldisk such as a CD-ROM, DVD-ROM or other optical media can be provided.In such instances, each can be connected to bus 18 by one or more datamedia interfaces. As will be further depicted and described below,memory 28 may include at least one program product having a set (e.g.,at least one) of program modules that are configured to carry out thefunctions of embodiments of the invention.

Program/utility 40, having a set (at least one) of program modules 42,may be stored in memory 28 by way of example, and not limitation, aswell as an operating system, one or more application programs, otherprogram modules, and program data. Each of the operating system, one ormore application programs, other program modules, and program data orsome combination thereof, may include an implementation of a networkingenvironment. Program modules 42 generally carry out the functions and/ormethodologies of embodiments of the invention as described herein.

Computer system/server 12 may also communicate with one or more externaldevices 14 such as a keyboard, a pointing device, a display 24, etc.;one or more devices that enable a user to interact with computersystem/server 12; and/or any devices (e.g., network card, modem, etc.)that enable computer system/server 12 to communicate with one or moreother computing devices. Such communication can occur via Input/output(I/O) interfaces 22. Still yet, computer system/server 12 cancommunicate with one or more networks such as a local area network(LAN), a general wide area network (WAN), and/or a public network (e.g.,the Internet) via network adapter 20. As depicted, network adapter 20communicates with the other components of computer system/server 12 viabus 18. It should be understood that although not shown, other hardwareand/or software components could be used in conjunction with computersystem/server 12. Examples, include, but are not limited to: microcode,device drivers, redundant processing units, external disk drive arrays,RAID systems, tape drives, and data archival storage systems, etc.

Referring now to FIG. 8, illustrative cloud computing environment 50 isdepicted. As shown, cloud computing environment 50 comprises one or morecloud computing nodes 10 with which local computing devices used bycloud consumers, such as, for example, personal digital assistant (PDA)or cellular telephone 54A, desktop computer 54B, laptop computer 54C,and/or automobile computer system 54N may communicate. Nodes 10 maycommunicate with one another. They may be grouped (not shown) physicallyor virtually, in one or more networks, such as Private, Community,Public, or Hybrid clouds as described hereinabove, or a combinationthereof. This allows cloud computing environment 50 to offerinfrastructure, platforms and/or software as services for which a cloudconsumer does not need to maintain resources on a local computingdevice. It is understood that the types of computing devices 54A-N shownin FIG. 8 are intended to be illustrative only and that computing nodes10 and cloud computing environment 50 can communicate with any type ofcomputerized device over any type of network and/or network addressableconnection (e.g., using a web browser).

Referring now to FIG. 9, a set of functional abstraction layers providedby cloud computing environment 50 (FIG. 8) is shown. It should beunderstood in advance that the components, layers, and functions shownin FIG. 9 are intended to be illustrative only and embodiments of theinvention are not limited thereto. As depicted, the following layers andcorresponding functions are provided:

Hardware and software layer 60 includes hardware and softwarecomponents. Examples of hardware components include: mainframes 61; RISC(Reduced Instruction Set Computer) architecture based servers 62;servers 63; blade servers 64; storage devices 65; and networks andnetworking components 66. In some embodiments, software componentsinclude network application server software 67 and database software 68.

Virtualization layer 70 provides an abstraction layer from which thefollowing examples of virtual entities may be provided: virtual servers71; virtual storage 72; virtual networks 73, including virtual privatenetworks; virtual applications and operating systems 74; and virtualclients 75.

In one example, management layer 80 may provide the functions describedbelow. Resource provisioning 81 provides dynamic procurement ofcomputing resources and other resources that are utilized to performtasks within the cloud computing environment. Metering and Pricing 82provide cost tracking as resources are utilized within the cloudcomputing environment, and billing or invoicing for consumption of theseresources. In one example, these resources may comprise applicationsoftware licenses. Security provides identity verification for cloudconsumers and tasks, as well as protection for data and other resources.User portal 83 provides access to the cloud computing environment forconsumers and system administrators. Service level management 84provides cloud computing resource allocation and management such thatrequired service levels are met. Service Level Agreement (SLA) planningand fulfillment 85 provide pre-arrangement for, and procurement of,cloud computing resources for which a future requirement is anticipatedin accordance with an SLA.

Workloads layer 90 provides examples of functionality for which thecloud computing environment may be utilized. Examples of workloads andfunctions which may be provided from this layer include: mapping andnavigation 91; software development and lifecycle management 92; virtualclassroom education delivery 93; data analytics processing 94;transaction processing 95; and self-driving vehicle control processing96 (for directing SDVs away from emergency vehicles as describedherein).

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the presentinvention. As used herein, the singular forms “a”, “an” and “the” areintended to include the plural forms as well, unless the context clearlyindicates otherwise. It will be further understood that the terms“comprises” and/or “comprising,” when used in this specification,specify the presence of stated features, integers, steps, operations,elements, and/or components, but do not preclude the presence oraddition of one or more other features, integers, steps, operations,elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of various embodiments of the present invention has beenpresented for purposes of illustration and description, but is notintended to be exhaustive or limited to the present invention in theform disclosed. Many modifications and variations will be apparent tothose of ordinary skill in the art without departing from the scope andspirit of the present invention. The embodiment was chosen and describedin order to best explain the principles of the present invention and thepractical application, and to enable others of ordinary skill in the artto understand the present invention for various embodiments with variousmodifications as are suited to the particular use contemplated.

Any methods described in the present disclosure may be implementedthrough the use of a VHDL (VHSIC Hardware Description Language) programand a VHDL chip. VHDL is an exemplary design-entry language for FieldProgrammable Gate Arrays (FPGAs), Application Specific IntegratedCircuits (ASICs), and other similar electronic devices. Thus, anysoftware-implemented method described herein may be emulated by ahardware-based VHDL program, which is then applied to a VHDL chip, suchas a FPGA.

Having thus described embodiments of the present invention of thepresent application in detail and by reference to illustrativeembodiments thereof, it will be apparent that modifications andvariations are possible without departing from the scope of the presentinvention defined in the appended claims.

What is claimed:
 1. A method comprising: receiving, at a receiverassociated with a self-driving vehicle (SDV), a message including acurrent location of an emergency vehicle that is responding to anemergency and a planned route for the emergency vehicle that includes afirst street; determining that the SDV will impede the emergency vehicleon the first street based on a currently planned route of the SDV;automatically controlling the SDV to take a second street, parallel tothe first street, and thereby avoid impeding the emergency vehicle; andtransmitting, to a server associated with the emergency vehicle, atraffic information message informing traffic pattern conditionsexisting proximate the SDV and predictable to impede the emergencyvehicle on the currently planned route.
 2. The method of claim 1,wherein the SDV is initially operating in manual mode in which the SDVis manually controlled by a human driver of the SDV, and wherein themethod of claim 1 further comprises: switching the SDV from the manualmode to an autonomous mode.
 3. The method of claim 1, furthercomprising: retrieving historical data associated with traffic patternconditions of the planned route for the emergency vehicle; and adjustingthe currently planned route of the SDV based on the historical dataassociated with the traffic pattern conditions of the planned route forthe emergency vehicle.
 4. The method of claim 1, further comprising:adjusting a distance between the SDV and another vehicle around the SDVbased on a predefined minimum distance, wherein the predefined minimumdistance is wide enough to allow the emergency vehicle to pass throughbetween the SDV and the another vehicle.
 5. A non-transitory computerreadable storage medium comprising computer-readable instructions, whichwhen executed by a computing system, cause the computing system to:receive, at a receiver associated with a self-driving vehicle (SDV), amessage including a current location of an emergency vehicle that isresponding to an emergency and a planned route for the emergency vehiclethat includes a first street; determine that the SDV will impede theemergency vehicle on the first street based on a currently planned routeof the SDV; automatically control the SDV to take a second street,parallel to the first street, and thereby avoid impeding the emergencyvehicle; and transmit, to a server associated with the emergencyvehicle, a traffic information message informing traffic patternconditions existing proximate the SDV and predictable to impede theemergency vehicle on the currently planned route.
 6. The non-transitorycomputer readable storage medium of claim 5, wherein the SDV isinitially operating in manual mode in which the SDV is manuallycontrolled by a human driver of the SDV, and wherein the instructions,which when executed by the computing system, further cause the computingsystem to: switch the SDV from the manual mode to an autonomous mode. 7.The non-transitory computer readable storage medium of claim 5, whereinthe instructions, which when executed by the computing system, furthercause the computing system to: adjust a distance between the SDV andanother vehicle around the SDV based on a predefined minimum distance,wherein the predefined minimum distance is wide enough to allow theemergency vehicle to pass through between the SDV and the anothervehicle.
 8. A computer system comprising: a processor; and a computerreadable medium comprising instructions stored therein, which whenexecuted by the processor, cause the processor to: receive, at areceiver associated with a self-driving vehicle (SDV), a messageincluding a current location of of an emergency vehicle that isresponding to an emergency and a planned route of the emergency vehiclethat includes a first street; determine that the SDV will impede theemergency vehicle on the first street based on a currently planned routeof the SDV; automatically control the SDV to take a second street,parallel to the first street, and thereby avoid impeding the emergencyvehicle; and transmit, to a server associated with the emergencyvehicle, a traffic information message informing traffic patternconditions existing proximate the SDV and predictable to impede theemergency vehicle on the currently planned route.
 9. The computer systemof claim 8, wherein the SDV is initially operating in manual mode inwhich the SDV is manually controlled by a human driver of the SDV, andwherein the instructions, which when executed by the processor, furthercause the processor to: switch the SDV from the manual mode to anautonomous mode.
 10. The computer system of claim 8, wherein theinstructions, which when executed by the processor, further cause theprocessor to: adjust a distance between the SDV and another vehiclearound the SDV based on a predefined minimum distance, wherein thepredefined minimum distance is wide enough to allow the emergencyvehicle to pass through between the SDV and the another vehicle.
 11. Themethod of claim 1, wherein the message includes a destination of theemergency vehicle, the method further comprising: predicting the plannedroute of the emergency vehicle based on the message.
 12. The method ofclaim 1, further comprising: determining a presence of one or moreobstacles on the planned route of the emergency vehicle, wherein thetraffic information message includes the presence of the one or moreobstacles along the planned route of the emergency vehicle.
 13. Themethod of claim 1, wherein the message further includes a profile of anoccupant of the emergency vehicle.
 14. The method of claim 2, furthercomprising: adjusting a level of autonomous control of the autonomousmode based on one or more characteristics of an occupant in the SDV. 15.The non-transitory computer readable storage medium of claim 5, whereinthe instructions, which when executed by the computing system, furthercause the computing system to: determine a presence of one or moreobstacles on the planned route of the emergency vehicle, wherein thetraffic information message includes the presence of the one or moreobstacles along the planned route of the emergency vehicle.
 16. Thenon-transitory computer readable storage medium of claim 5, wherein themessage further includes a profile of an occupant of the emergencyvehicle.
 17. The non-transitory computer readable storage medium ofclaim 6, wherein the instructions, which when executed by the computingsystem, further cause the computing system to: adjust a level ofautonomous control of the autonomous mode based on one or morecharacteristics of an occupant in the SDV.
 18. The computer system ofclaim 8, wherein the instructions, which when executed by the processor,further cause the processor to: determine a presence of one or moreobstacles on the planned route of the emergency vehicle, wherein thetraffic information message includes the presence of the one or moreobstacles along the planned route of the emergency vehicle.
 19. Thecomputer system of claim 9, wherein the message further includes aprofile of an occupant of the emergency vehicle.
 20. The computer systemof claim 9, wherein the instructions, which when executed by theprocessor, further cause the processor to: adjust a level of autonomouscontrol of the autonomous mode based on one or more characteristics ofan occupant in the SDV.